Hello, 各位 iT 邦幫忙 的粉絲們大家好~~~

本篇是 建構安全軟體開發 系列文的 EP30。

Input Validation

有 "輸入" 的機會就永遠要 "同時" 記得以下兩點(注意是 "同時")：

• 只要有 "輸入" 就會有 "邪惡"。 (All input data is evil.)
• 信任，但要查驗。 (Trust, but verify.)

所以換句話說就是 "Never Trust, Always Verify"，對於 輸入 都是採取 "零信任(Zero Trust)" 的安全措施去檢驗。

在任何的網路應用服務(形成了 Client-Server 的兩端)當中，不僅是在 Client 端要驗證輸入之外，在 Server 端也同時要驗證輸入，原因是 Client 端的資料輸入驗證機制很容易透過一些手法(無論是誤用、濫用甚至是惡意)跳過後，直接把資料透過連線往 Server 端送，若 Server 端不採取驗證機制，全然相信連線送上來的資料，那就很容易被 inject 攻擊了；反之若 Client 端不作任何進行驗證的機制，只仰賴 Server 端驗證，那對 Server 端又是個很糟糕的問題了。

要查驗 input 的資料方向為下列幾個：

• Type (型別)
• Length (長度)
• Format (格式)
• Escape (特殊字符)

而手法上以下提供幾種：

• Filtering (篩選制度)

  • White List (a.k.a Allow List)： 列出白名單，例如只有丙、申、己、巳才被允許，其餘的就都拒絕。也就是說只允許丙、申、己、巳能通過。
  • Black List (a.k.a Deny List)： 列出黑名單，例如只有丙、申、己、巳才要拒絕，其餘就都可允許。也就是說丙、申、己、巳就拒絕，其他的都通過。

  所以，很明顯的 Black List (a.k.a Deny List) 在絕大多數的情況底下是不被使用的，都是以的 White List (白名單)去設計 Filtering 的驗證為主要手法。

• Canonicalization (正規化/標準化) 下列是幾個常見應用的典型場景：

  • Filenames: 因為 OS 在檔案系統的設計中，有使用幾個特殊的符號，代表其特殊的運用意義，例如: "~"、"."、".."、"%"...等，而在 Windows 與 Unix-like 系統當中，檔案路徑的分隔符號也有所差異，所以發生 "Directory Traversal Attacks" 時有所聞，直至去年 (2021 年) 才被發現 Apache 的 CVE 漏洞: CVE-2021-41773 就是這類的問題所產生的漏洞。
    • 在 .NET 程式當中，能盡量使用 System.IO 底下的類別庫處理檔案系統路徑，就避免自己直接撰寫。另外在可必要的檔案路徑或檔案名稱的輸入處理當中呼叫 GetInvalidFileNameChars 與 GetInvalidPathChars 檢查不該出現的字符。
  • Unicode: 在這邊可參考 Unicode Normalization 的解釋。
  • URL: 在網際網路中透過在網頁中透過 HTML 中的 canonical 標記 (aka "rel canonical") 來定義某個網址才是正本，其他都是副本。常被用在 SEO 的處理，可參考MOZ: Canonicalization。
  • XML: 可參考 Canonical XML Version 2.0
  • Json: 可參考 RFC 8785 JSON Canonicalization Scheme (JCS)

  若想瞭解沒有透過 Canonicalization 進行 input 驗證，可能會遭受的攻擊方式，可參考下列網址：
  https://resources.infosecinstitute.com/topic/canonicalization-attack/

寫到這邊，剛好看到 CVE 發佈起因於 "Insufficient validation of untrusted input" 的安全性漏洞 CVE: 2022-3201：

然後 Chrome 針對此安全性漏洞做出了修正並發佈更新：
2022/9/14 第一次修正：

2022/9/27 第二次修正：

Output Sanitization

輸出都需要進行適合的過濾與編碼。就如 HTML 網頁的輸出也是需要進行(對讀取網頁的應用是一種輸入)：

• 若 .NET 程式可考慮運用 HtmlSanitizer
• 若 Java 程式可考慮運用 java-html-sanitizer

而其實要掌握的就是處理有無特殊的控制字元/指令出現在輸出內容當中，以避免遭受攻擊。

Other Topics

其實還有很多點要顧慮的處理，例如：

• Error and Exception Handling (錯誤與例外處理)
• Secure Logging and Auditing (安全日誌紀錄與稽核)
• Session Management (狀態管理)
• Safe Application Programming Interface (運用安全 API )
• Memory Management (記憶體管理)
• Tokenization (代碼化交易): 在交易的過程當中把敏感的資訊進行代碼化處理 (你他媽不是用 Base64 就好...)
• Isolation (核心獨立隔離區)
• Crypotography (密碼學): 除了瞭解當代密碼學之外，為了可預期的量子電腦的發展，目前密碼學已經開始往 PQC: Post-Quantum Cryptography 的方向前進，可觀看下列網址報導：
  https://www.ithome.com.tw/news/141987
• Access Control (存取控制)

真的太多了，希望未來再繼續談下去...(應該有機會的吧！？)

Third-Party Code

最後要提的使用第三方程式該注意的：

可參考 OWASP : Software Component Verification Standard，縮寫為 SCVS。

在 SCVS 中共分成 6 種：

• V1: Inventory
• V2: Software Bill of Materials (SBOM)
• V3: Build Environment
• V4: Package Management
• V5: Component Analysis
• V6: Pedigree and Provenance

與 3 個認證層級，等級隨數字由低到高：

• SCVS Level 1 初階認證，有最低階保證有按照基本的規範進行分析即可。
• SCVS Level 2 中階認證，完成 Level 1 的標準外，還有針對敏感領域進行分析或有進一步審慎額外處理的。
• SCVS Level 3 高階認證，達到 Level 2 的標準外，還能更高度審慎的確保敏感資料或軟體處理使用的。

就算該第三方軟體沒有取得 SCVS 認證， OWASP 仍建議若該第三方軟體是 Open-Source 時，需注意的相關的政策指引：
Open-Source Policy Guidance

• All organizations that use open source software should have an open source policy.
• The open source policy is supported and enforced by cross-functional stakeholders.
• The open source policy should address:
  • The age of a component based on its release or published date.
  • How many major or minor revisions old are acceptable.
  • Guidance for keeping components continuously updated via automation.
  • Exclusion criteria for components with known vulnerabilities.
  • Mean-time-to-remediate criteria for updating at-risk components.
  • Restrictions on using components that are end-of-life or end-of-support.
  • Criteria for supplier selection or exclusion.
  • Usage-based list of acceptable licenses.
  • Prohibited components list.
  • Mechanisms and permissions for providing modifications back to the community producing the component.

當然，也可以透過一些工具來進行分析：

• Software Composition Analysis : SCA
  • 如果是 .NET 程式可以透過，前一回提到的 "Code Quality Rules" (程式碼品質規則)：
    https://learn.microsoft.com/zh-tw/dotnet/fundamentals/code-analysis/quality-rules/

程式碼安全重用

• Dependency check
  可參考 https://github.com/jeremylong/DependencyCheck
• Dependency Track
  可參考 https://dependencytrack.org/

最後，感謝各位 iThelp 的粉絲收看這 "建構安全軟體開發" 這 30 回的文章，後會有期！